The invention generally relates to a method for allowing an operating system to be upgraded without destroying the compatibility of applications written for the operating system. By distinguishing between applications which are going to customize the operating system controls from those applications which are not going to customize the operating system controls, the operating system can determine which applications can use upgraded operating system controls when they become available.
Many computer systems provide a window-based user interface through which a user can interface with a computer program. A window is an area, typically rectangular, of a display device in which the computer program displays its output. A window may contain several different types of xe2x80x9cfieldsxe2x80x9d into which the computer program can display data. For example, in one field the computer program can display a label to be viewed by a user, and in another field the computer program can echo characters entered by a user with a keyboard. Each of these fields is typically implemented as a child window of the window in which they are contained.
FIG. 1 illustrates a prior art window that contains controls. Controls are graphical user interface elements which provide access by a user to any properties or events in an object-oriented programming environment. Because the window shown in FIG. 1 contains information relating to properties of a document, it is known as a property sheet. A property specifies certain characteristics of an object, such as a document. For example, the properties of a document may include the name of the author and the date of creation, whereas the properties of a character may include font and color. The property sheet 11 contains five property pages: general 12, summary 13, statistics 14, contents 15, and custom 16. Each property page is a child window of the property sheet and contains various controls, which are child windows of the property page. For example, in FIG. 1, the custom property page has been selected and contains controls in the form of combobox 17, edit box 18, check box 19. Other examples of property pages are a general property page, a summary property page, a statistics property page, and a contents property page. As shown in FIG. 1, each of these property pages can be accessed by a user.
There are several reasons why it is difficult to innovate the user interface in an operating system. The controls (window classes, like button, edit, etc.) are used not only by the operating system itself, but also by applications that want the same xe2x80x9clook and feelxe2x80x9d as the operating system. The operating system exposes its controls and encourages developers of applications to make use of them. Many of the controls can be customized to fit particular application needs. This type of customization can be explicit, for example an xe2x80x98owner draw buttonxe2x80x99, or implicit by xe2x80x98subclassingxe2x80x99 a window.
If an application makes use of either of these customization methods, certain assumptions about the controls are made by the application developer, the predominant one being that those controls will not change behavior dramatically. Applications make use of this kind of customization to make their applications look more exciting, or to add functionality to controls that the operating system did not provide, for example, such as providing hot tracking. Hot tracking, for example, is a mechanism by which a selected button on a user interface can be made to look three dimensional when the pointer is located over the button.
If an application vendor subclasses a button control to add hot tracking, for example, it is difficult for the operating system to add hot tracking in the future. Some applications, however, do not make use of these customization options, often to improve their time-to-market or because it is not a requirement for their customers. Since the operating system can not distinguish between non-customized and customized applications, applications that are not customized suffer because they can not take advantage of upgrades to the operating system that could have been made but are not made for fear of not being compatible with applications which have customized their controls. Failure of an operating system to remain compatible with applications is also known as xe2x80x9cbreakingxe2x80x9d applications.
Currently, there is only a limited solution to this problem. Applications are written to a specific version of the operating system, and the application is marked with this version number, e.g. 3.1 (for Windows(copyright) 3.1) and 4.0 (for Windows(copyright) 95). The operating system can read the version number and make some use of the version number to determine the xe2x80x9clook and feelxe2x80x9d the operating system should provide to the application, and what xe2x80x9ccommon dialogsxe2x80x9d the application can use. For example, in a single code path, for drawing the edges of a button, the operating system will determine the application version, and draw the edges xe2x80x98flat or xe2x80x98raisedxe2x80x99 depending on the xe2x80x98look and feelxe2x80x99 of that version of the operating system. This is to match the user interface of the application, which may contain its own controls that are xe2x80x98flatxe2x80x99, as was the previous xe2x80x98look and feelxe2x80x99 of the operating system. Modifications such as these are tested very thoroughly, for many months, on thousands of applications to ensure that the modification does not break any of the applications. The levels of change capable are very low, so only minor changes can be made. If it is found that a particular application xe2x80x98breaksxe2x80x99 under the new behavior, a judgement call is made to either include the changed behavior or remove it. If it is decided to keep the new behavior, more code is added to exclude this new behavior for any particular application which will be broken by the new behavior.
Presently, when a developer wants to create a control, such as a button, in an application, the following line of code, for example, can be used:
HWND hwnd=CreateWindow(xe2x80x9cBUTTONxe2x80x9d . . . )
In this case, the developer is explicitly asking for a window whose classname is BUTTON. The operating system provides this window, but may also perform checks against the version number in the application to slightly modify its behavior.
As noted above, developers are free to customize this control, and can modify its behavior by using, for example, the following line of code:
SetWindowLong(hwnd, GWL_WNDPROC,(DWORD)myWndProc)
Once this line of code is used, the myWndProc fiction will override all the windows messages that are sent to the control to add or modify the behavior of the BUTTON control. As a result, it is difficult for the operating system to improve the functionality of the BUTTON control.
The above-described shortcomings, disadvantages and problems are addressed by the invention by providing a naming convention which distinguishes between controls that will be or may be customized and controls that will not be customized so as to allow the operating system to upgrade its controls without destroying the compatibility of applications which have previously customized the operating system controls.
The controls of an operating system are generally made available for use by applications running on the operating system. The application developer has the option of using the control in the same manner that the operating system uses the control or the developer can customize the control by changing a set of features that define the control. When the control is not going to be customized, the developer identifies in the code of the application that the control will not be customized. Likewise, the developer identifies in the code of the application that the control will be customized.
When the application is running on the operating system and a control is requested, the operating system first determines whether the control is identified as being customized or non-customized. If the control is not going to be customized, the operating system is free to use an upgraded set of features to create the control if they are available. If the control is going to be customized, the operating system will use the specific set of features associated with the control of the specific version of the operating system for which the application was written. Thus, the operating system can be upgraded without fear of breaking applications which have customized their controls.